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ABSTRACT 

This  lnforaal  paper  Introduces  the  LISP  Machine,  describes  the  goals  and  current 
status  of  the  project,  and  explicates  sons  of  the  hey  ideas.  It  covers  the  LISP 
machine  implementation,  LISP  as  a system  language,  input/output,  representation 
of  data,  representation  of  programs,  control  structures,  storage  organization, 
garbage  collection,  the  editor,  and  the  current  status  of  the  work. 

This  report  describes  research  done  at  the  Artificial  Intelligence  Laboratory  of 
the  Massachusetts  Institute  of  Technology.  Support  for  the  laboratory's 


artificial  intelligence  research  is  provided  in  part  by  the  Advanced  Research 


Projects  Agency  of  the  Department  of  Defense  under  Office  of  Naval  Research 


contract  N00014-73-C-0643. 
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INTRODUCTION: 

The  LISP  Machine  is  a new  computer  systea  designed  to  provide  a high 
porforaance  and  econoaical  implementation  of  the  LISP  programing  language. 

The  LISP  language  is  used  widely  in  the  artificial  intelligence  research 
community,  and  is  rapidly  gaining  adherents  outside  this  group.  Host  serious 
LISP  usage  has  historically  been  on  the  DEC  PDP-10  computer,  and  both  "major" 
implementations  (InterLisp  at  BBN/XEROX  and  Maclisp  at  N.I.T.)  were  originally 
done  on  the  PDP-10.  Our  personal  experience  has  largely  been  with  the  Maclisp 
dialect  of  LISP,  which  was  originally  written  in  1965. 

Over  the  years,  dramatic  changes  have  taken  place  in  the  Maclisp 
implementation.  At  a certain  point,  however,  modification  and  reimplementation 
of  a language  on  a given  machine  can  no  longer  efficiently  gloss  over  basic 
problems  in  the  architecture  of  the  computer  system.  We,  and  many  others, 
believe  this  is  now  the  case  on  the  PDP-10  and  similar  time-shared  computer 
systems . 

Time  sharing  was  introduced  when  it  became  apparent  that  computers  are 
easier  to  use  in  an  interactive  fashion  than  in  a batch  system,  and  that  during 
an  interactive  session  a user  typically  uses  only  a small  fraction  of  the 
processor  and  memory  available;  often  during  much  of  the  time  his  process  is 
idle  or  waiting,  and  so  the  computer  can  be  multiplexed  among  many  users  while 
giving  each  the  impression  that  he  is  on  his  own  machine. 

However,  in  the  Lisp  community  there  has  been  a strong  trend  towards 
programs  which  are  very  highly  interactive,  very  large,  and  use  a good  deal  of 
computer  time;  such  programs  include  advanced  editors  and  debuggers,  the  HACSYHA 
system,  and  various  programming  assistants.  When  running  programs  such  as  these, 
which  spend  very  significant  amounts  of  time  supporting  user  interactions,  time 
sharing  systems  such  as  the  PDP-10  run  into  increased  difficulties.  Not  only  is 
the  processor  Incapable  of  providing  either  reasonable  throughput  or  adequate 
response  time  for  a reasonable  number  of  users,  but  the  competition  for  main 
memory  results  in  large  amounts  of  time  being  spent  swapping  pages  in  and  out  (a 
condition  known  as  "thrashing").  Larger  and  larger  processors  and  memory,  and 
more  and  more  complex  operating  systems,  are  required,  with  more  than 
proportionally  higher  cost,  and  still  the  competition  for  memory  remains  a 
bottleneck.  The  programs  are  sufficiently  large,  and  the  interactions 
sufficiently  frequent,  that  the  usual  time-sharing  strategy  of  swapping  the 
program  out  of  memory  while  waiting  for  the  user  to  Interact,  then  swapping  it 
back  in  when  the  user  types  something,  cannot  bo  successful  because  the  swapping 
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cannot  happen  fast  enough. 

The  Lisp  Machine  Is  a personal  coaputer.  Personal  coaputlng  aeans  that 
the  processor  and  aain  aeaory  are  not  tiae-dlvlslon  multiplexed,  Instead  each 
person  gets  his  own.  The  personal  coaputatlon  systen  consists  of  a pool  of 
processors,  each  with  its  own  aain  aeaory,  and  its  own  disk  for  swapping.  When  a 
user  logs  in,  he  is  assigned  a processor,  and  he  has  exclusive  use  of  it  for  the 
duration  of  the  session.  When  he  logs  out,  the  processor  is  returned  to  tho 
pool,  for  the  next  person  to  use.  This  way,  there  is  no  coapetltion  froa  other 
users  for  aeaory;  the  pages  the  user  is  frequently  referring  to  reaaln  in  core, 
and  so  swapping  overhead  is  considerably  reduced.  Thus  the  Lisp  Machine  solves  a 
basic  problea  of  tine  sharing  Lisp  systeas. 

The  user  also,  gets  a auch  higher  degree  of  service  froa  a Lisp  aachlna 
than  froa  a tiaesharing  systea,  because  he  can  use  the  full  throughput  capacity 
of  the  processor  and  the  disk.  Although  these  are  quite  inexpensive  coapared  to 
those  used  in  POP- 10  tiaesharing  systeas,  they  are  coaparable  1m  speed.  In  fact, 
since  disk  access  tines  are  aalnly  Halted  by  physical  considerations,  it  often 
turns  out  that  the  disk  used  in  a personal  coaputer  systea  is  less  .expensive 
simply  because  of  its  saaller  size,  and  has  fully  coaparable  throughput 
charactistlcs  to  the  larger  disk  used  by  a tiaesharing  systea. 

In  a single-user  aachine,  there  is  no  penalty  for  interactiveness,  since 
there  are  no  conpetlng  users  to  steal  a program's  aeaory  while  it  Is  waiting  for 
its  user  to  type.  Thus  the  Lisp  aachine  systenc  unlike  tine  sharing  systeas, 
encourages  highly  interactive  prograas.  It  puts  service  to  the  user  entirely 
ahead  of  efficiency  considerations. 

Another  problea  with  the  PDP-1Q  Lisp  iapleaentations  is  the  saall  address 
space  of  the  PDP-10  processor.  Many  Lisp  systeas,  such  as  HACSYHA  and  Woods's 
LUNAR  prograa,  have  difficulty  running  in  an  18-bit  address  space.  This  problea 
is  further  coapounded  by  the  Inefficiency  of  the  information  coding  of  compiled 
Lisp  code;  compilers  for  the  PDP-10  produce  only  a Halted  subset  of  the  large 
instruction  set  Bade  available  by  the  hardware,  and  usually  aake  inefficient  use 
of  the  addressing  nodes  and  fields  provided.  It  is  possible  to  design  much  more 
compact  Instruction  sets  for  Lisp  code.  Future  prograas  are  likely  to  be  quite  a 
bit  bigger;  intelligent  systeas  with  natural  language  front  ends  nay  well  be 
five  or  ten  tines  the  size  of  a PDP-10  address  space. 

The  Lisp  Machine  has  a 24  bit  virtual  address  space  and  a coapact 
instruction  set,  described  later  in  this  paper.  Thus  auch  larger  prograas  nay  be 
used,  without  running  into  address  space  limitations.  Since  the  Instruction  set 
is  designed  specifically  for  the  Lisp  language,  the  coapiler  is  auch  simpler  than 
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the  PDP-10  compiler,  providing  fester  and  aore  reliable  coapilation. 

The  Lisp  Machine's  coepact  size  and  simple  hardware  construction  are 
likely  to  Bake  it  Bore  reliable  than  other  Machines,  such  as  the  PDP-10;  the 
prototype  Machine  has  had  almost  no  hardware  failures. 

Much  of  the  inspiration  for  the  Lisp  Machine  project  coses  from  the 
pioneering  research  into  personal  coaputing  and  display-oriented  systeas  done  by 
Xerox's  Palo  Alto  Research  Center. 


THE  LISP  MACHINE  IMPLEMENTATION. 

Each  logged  in  user  of  the  Lisp  Machine  system  has  a processor,  a memory, 
a keyboard,  a display,  and  a Beans  of  getting  to  the  shared  resources. 
Terainals,  of  course,  are  placed  in  offices  and  various  rooas;  Ideally  there 
would  be  one  in  every  office.  The  processors,  however,  are  all  kept  off  in  a 
machine  room.  Since  they  nay  need  special  environaental  conditions,  and  often 
Bake  noise  and  take  up  space,  they  are  not  welcoae  office  companions.  The  nuaber 
of  processors  is  unrelated  to  the  number  of  terainals,  and  Bay  be  saaller 
depending  on  economic  circumstance. 

The  processor  is  implemented  with  a Microprogrammed  architecture.  It  is 
called  the  CONS  Machine,  designed  by  Tom  knight  [CONS].  CONS  is  a very 
unspecialized  machine  with  32-bit  data  paths  and  24-bit  address  paths.  It  has  a 
large  microcode  memory  (16k  of  48-blt  words)  to  acconaodate  the  large  amount  of 
specialized  microcode  to  support  Lisp.  It  has  hardware  for  extracting  and 
depositing  arbitrary  fields  in  arbitrary  registers,  which  substitutes  for  the 
specialised  data  paths  found  in  conventional  microprocessors.  It  does  not  have  a 
cache,  but  does  have  a "pdl  buffer"  (a  memory  with  hardware  push-down  pointer) 
which  acts  as  a kind  of  cache  for  the  stack,  which  is  where  most  of  the  memory 
references  go  in  Lisp. 

Using  a very  unspeclalized  processor  was  found  to  be  a good  idea  for 
several  reasons.  For  one  thing,  it  is  faster,  loss  expensive,  and  easier  to 
debug.  For  another  thing,  it  is  much  easier  to  microprogram,  which  allows  us  to 
write  and  debug  the  large  amounts  of  microcode  required  to  support  a 
sophisticated  Lisp  system  with  high  efficiency.  It  also  makes  feasible  a 
compiler  which  generates  microcode,  allowing  users  to  mlcrocomplle  some  of  their 
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functions  to  increase  performance. 

The  aeaory  is  typically  64k  of  core  or  seaiconductor  aeaory.  and  is 
expandable  to  about  1 Billion  words.  The  full  virtual  address  space  is  stored  on 
a 16  Billion  word  disk  and  paged  into  core  (or  seaiconductor)  aeaory  as  required. 
A given  virtual  address  is  always  located  at  the  saae  place  on  the  disk.  The 
access  tiae  of  the  core  aeaory  is  about  1 microsecond,  and  of  the  disk  about  25 
Billiseconds.  Additionally,  there  is  an  Internal  lk  buffer  used  for  holding  the 
top  of  the  stack  (the  PDL  buffer)  with  a 200ns  access  tiae  (see  [CONS]  for  aore 
detail). 


The  display  is  a raster  scan  TV  driven  by  a 1/4  Mbit  aeaory,  similar  to 
the  TV  display  system  now  in  use  on  the  Artificial  Intelligence  Lab's  POP- 10. 
Characters  are  drawn  entirely  by  software,  and  so  any  type  or  slse  of  font  can  be 
used,  including  variable  width  and  several  styles  at  the  saae  tiae.  One  of  the 
^ advantages  of  having  an  unspecialized  microinstruction  processor  such  as  CONS  is 

that  one  can  lapleaent  a flexible  teralnal  in  software  for  less  cost  than  an 
inflexible,  hardwired  conventional  teralnal.  The  TV  systea  is  easily  expanded  to 
support  gray  scale,  high  resolution,  and  color.  This  systea  has  been  shown  to  be 
very  useful  for  both  character  display  and  graphics. 

The  keyboard  is  the  saae  type  as  is  used  on  the  Artificial  Intelligence 
Lab  TV  display  systea;  it  has  several  levels  of  control/shifting  to  facilitate 
easy  single-keystroke  conaands  to  prograas  such  as  the  editor.  The  keyboard  is 
also  equipped  with  a speaker  for  beeping,  and  a pointing  device,  usually  a Bouse 
[MOUSE]. 

. 

The  shared  resources  are  accessed  through  a 10  Billion  bit/sec  packet 
switching  network  with  coapletely  distributed  control.  The  shared  resources  are 
to  Include  a highly  reliable  file  systea  implemented  on  a dedicated  computer 
equipped  with  state  of  the  art  disks  and  tapes,  specialized  I/O  devices  such  as 
high-quality  hardcopy  output,  special-purpose  processors,  and  connections  to  the 
outside  world  (e.g.  other  computers  in  the  building,  and  the  ARPANET). 

As  in  a tiae  sharing  systea,  the  file  systea  is  shared  between  users. 
Tiae  sharing  has  pointed  up  aany  advantages  of  a shared  file  systea,  such  as 
common  access  to  files,  easy  inter-user  coaaninication,  centralized  prograa 
aaintenance,  centralized  backup,  etc.  There  are  no  personal  disk  packs  to  bo 
lost,  dropped  by  users  who  are  not  competent  as  operators,  or  to  be  filled  with 
copies  of  old,  superseded  software. 
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The  complete  LISP  Machine,  including  processor,  aeaory,  disk,  terminal, 
and  connection  to  the  shared  file  system,  is  packaged  in  a single  19'  logic 
cabinet,  except  for  the  disk  which  is  free-standing.  The  complete  aachlne  would 
be  likely  to  cost  about  S80,000  if  commercially  produced.  Since  this  is  a 
complete,  fully-capable  system  (for  one  user  at  a tine),  it  can  substantially 
lower  the  cost  of  entry  by  new  organizations  into  serious  Artificial  Intelligence 
work. 


LISP  AS  A SYSTEM  LANGUAGE: 


In  the  software  of  the  Lisp  Machine  system,  code  is  written  In  only  two 
languages  (or  "levels*):  Lisp,  and  CONS  aachlne  microcode.  There  is  never  any 
reason  to  hand-code  aacrocode,  since  it  corresponds  so  closely  with  Lisp; 
anything  one  could  write  in  aacrocode  could  be  more  easily  and  clearly  written  in 
the  corresponding  Lisp.  The  READ,  EVAL,  and  PRINT  functions  are  coapletely 
written  in  Lisp,  including  their  subfunctions  (except  that  APPLY  of  compiled 
functions  is  in  alcro-code).  This  illustrates  the  ability  to  write  "system" 
functions  in  Lisp. 

In  order  to  allow  various  low-level  operations  to  be  performed  by  Lisp 
code,  a set  of  "sub -primitive"  functions  exist.  Their  naaes  by  convention  begin 
with  a "X",  so  as  to  point  out  that  they  are  capable  of  performing  unLlspy 
operations  which  nay  result  in  aeaningless  pointers.  These  functions  provide 
"machine  level"  capabilities,  such  as  performing  byte-deposits  into  memory.  The 
compiler  converts  calls  to  these  sub-priaitives  into  single  instructions  rather 
than  subroutine  calls.  Thus  Lisp-coded  low-level  operations  are  Just  as 
efficient  as  they  would  be  in  aachlne  language  on  a conventional  aachlne. 

In  addition  to  sub-priaitives,  the  ability  to  do  systen  programing  in 
Lisp  depends  on  the  Lisp  machine's  augaented  array  feature.  There  are  several 
types  of  arrays,  one  of  which  is  used  to  implement  character  strings.  This  makes 
it  easy  and  efficient  to  manipulate  strings  either  as  a whole  or  character  by 
character.  An  array  can  have  a "leader",  which  is  a little  vector  of  extra 
information  tacked  on.  The  leader  always  contains  Lisp  objects  while  the  array 
often  contains  characters  or  snail  packed  nuabers.  The  leader  fadlititates  the 
use  of  arrays  to  represent  various  kinds  of  abstract  object  types.  The  presence 
in  the  language  of  both  arrays  and  lists  gives  the  programmer  sore  control  over 
data  representation. 
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A traditional  weakness  of  Lisp  has  been  that  functions  have  to  take  a 
fixed  number  of  arguments.  Various  lapleaentatlons  have  added  kludges  to  allow 
variable  nuabers  of  arguments;  these,  however,  tend  either  to  slow  down  the 
function-calling  aechanlsa,  even  when  the  feature  is  not  used,  or  to  force 
peculiar  prograaaing  styles.  Llsp-aachlne  Lisp  allows  functions  to  have  optional 
paraaeters  with  autoaatic  user-controlled  defaulting  to  an  arbitrary  expression 
in  the  case  where  a corresponding  arguaent  is  not  supplied.  It  is  also  possible 
to  have  a "rest"  paraaeter,  which  is  bound  to  a list  of  the  arguaents  not  bound 
to  previous  paraaeters.  This  is  frequently  important  to  slaplify  systea  programs 
and  their  Interfaces. 

A slailar  problea  with  Lisp  function  calling  occurs  when  one  wants  to 
return  aore  than  one  velue.  Traditionally  one  either  returns  a list  or  stores 
soae  of  the  values  into  global  variables.  In  Lisp  aachine  Lisp,  there  is  a 
multiple-value-return  feature  which  allows  multiple  values  to  be  returned  without 
going  through  either  of  the  above  subterfuges. 

Lisp's  functional  orientation  and  encourageaent  of  a prograaaing  style  of 
small  modules  and  uniform  data  structuring  is  appropriate  for  good  systea 
prograaaing.  The  Lisp  aachine 's  aicro-coded  subroutine  calling  aechanlsa  allows 
it  to  also  be  efficient. 

Paging  is  handled  entirely  by  the  microcode,  and  is  considered  to  be  at  a 
very  low  level  (lower  level  than  any  kind  of  scheduling).  Making  the  guts  of  the 
virtual  aeaory  invisible  to  all  Lisp  code  and  aost  microcode  helps  keep  things 
simple.  It  would  not  be  practical  in  a time  sharing  systea,  but  in  a one-user 
aachine  it  is  reasonable  to  put  paging  at  the  lowest  level  and  forget  about  it, 
accepting  the  fact  that  sonatinas  the  aachine  will  be  tied  up  waiting  for  the 
disk  and  unable  to  run  any  Lisp  code. 

nicro-coded  functions  can  be  called  by  Lisp  code  by  the  usual  Lisp 
calling  mechanisa,  and  provision  is  aade  for  aicro-coded  functions  to  call 
aacro-coded  functions.  Thus  there  is  a uniform  calling  convention  throughout  the 
entire  systea.  This  has  the  effect  that  uniform  subroutine  packages  can  be 
written,  (for  exaaple  the  TV  package,  or  the  EDITOR  package)  which  can  be  called 
by  any  other  prograa.  (A  slailar  capability  is  provided  by  Hultics,  but  not  by 
ITS  nor  TENEX). 

Many  of  the  capabilities  which  systea  prograaaers  write  over  and  over 
again  in  an  ad  hoc  way  are  built  into  the  Lisp  language,  and  are  sufficiently 
good  in  their  Lisp-provided  fora  that  it  usually  is  not  necessary  to  waste  tlao 
worrying  about  how  to  lapleaent  better  ones.  These  Include  syabol  tables, 
storage  aanageaent,  both  fixed  and  flexible  data  structures,  function-calling. 
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and  an  lntaractlva  user  lntarfaca. 

Our  axparlanca  has  baan  that  we  can  daslgn,  coda,  and  dabug  nan  faaturas 
■uch  fastar  in  Lisp-machine  prograns  than  In  PDF- 10  programs,  whether  they  are 
written  In  assanblar  language  or  In  traditional  "higher* level*  languages. 
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INPUT/OUTPUT: 

Low  level: 

The  Lisp  Machine  processor  (CONS)  has  two  busses  used  for  accessing 
external  devices:  the  "XBUS",  and  the  "UNIBUS".  The  XBUS  Is  32  bits  wide,  and 
is  used  for  the  disk  and  for  nain  nenory.  The  UNIBUS  is  a standard  PDP-11  16-bit 
bus,  used  for  various  I/O  devices.  It  allows  connonly  available  PDP-11 
compatible  devices  to  be  easily  attached  to  the  Lisp  Machine. 

Input/output  software  is  essentially  all  written  in  Lisp;  the  only 
functions  provided  by  the  nicrocode  are  XUNIBUS-READ  and  XUNIBUS-VRITE,  which 
know  the  offset  of  the  UNIBUS  in  physical  address  space,  and  refer  to  the 
corresponding  location.  The  only  real  reason  to  have  these  in  microcode  is  to 
avoid  a timing  error  which  can  happen  with  some  devices  which  have  side  effects 
when  read.  It  is  Lisp  programs,  not  special  microcode,  which  know  the  location 
and  function  of  the  registers  in  the  keyboard,  mouse,  TV,  and  cable  network 
interfaces.  This  makes  the  low-level  I/O  code  just  as  flexible  and  easy  to 
modify  as  the  high  level  code. 

There  are  also  a couple  of  mlcrocoded  routines  which  speed  up  the  drawing 
of  characters  in  the  TV  memory.  These  do  not  do  anything  which  could  not  be  done 
in  Lisp,  but  they  are  carefully  hand-coded  in  microcode  because  we  draw  an  awful 
lot  of  characters. 

High  level: 

Nany  programs  perform  simple  stream-oriented  (sequential  characters)  I/O. 
In  order  that  these  programs  be  kept  device-independent,  there  is  a standard 
definition  of  a "stream”:  a stream  is  a functional  object  which  takes  one 
required  argument  and  one  optional  argument.  The  first  ergument  is  a symbol 
which  is  a "command"  to  the  stream,  such  as  "TYI",  which  means  "input  one 
character,  and  return  it"  and  "TYO",  which  means  "output  one  character”.  The 
character  argument  to  the  TYO  command  is  passed  in  the  second  argument  to  the 
stream.  There  are  several  other  standard  optional  stream  operations,  for  several 
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purposes  including  higher  efficiency.  In  addition  particular  devices  can  define 
additional  operations  for  their  own  purposes. 

Streams  can  be  used  for  I/O  to  files  in  the  file  system,  strings  inside 
the  Lisp  Machine,  the  terminal,  editor  buffers,  or  anything  else  which  is 
naturally  represented  as  sequential  characters. 

For  I/O  which  is  of  necessity  device-dependent,  such  as  the  sophisticated 
operations  performed  on  the  TV  by  the  editor,  which  include  multiple  blinkers  and 
random  access  to  the  screen,  special  packages  of  Lisp  functions  are  provided,  and 
there  is  no  attempt  to  be  device- independent.  (See  documentation  on  the  TV  and 
network  packages). 

In  general,  we  feel  no  regret  at  abandoning  device  independence  in 
interactive  programs  which  know  they  are  using  the  display.  The  advantages  to  be 
gained  from  sophisticated  high -bandwidth  display-based  interaction  far  outweigh 
the  advantages  of  device-independence.  This  does  mean  that  the  Lisp  machine  is 
really  not  usable  from  other  than  its  own  terminal;  in  particular,  it  cannot  be 
used  remotely  over  the  ARPANET. 


REPRESENTATION  OF  DATA: 

A Lisp  object  in  Maclisp  or  InterLisp  is  represented  as  an  18  bit 
pointer,  and  the  datatype  of  the  object  is  determined  from  the  pointer;  each 
page  of  memory  can  only  contain  objects  of  a single  type.  In  the  Lisp  machine. 
Lisp  objects  are  represented  by  a 5 bit  datatype  field,  and  a 24  bit  pointer. 
(The  Lisp  machine  virtual  address  space  is  24  bits).  There  are  a variety  of 
datatypes  (most  of  the  32  possible  codes  are  now  in  use),  which  have  symbolic 
names  such  as  DTP-LIST,  DTP-SYMBOL,  DTP-FIXNUN,  etc. 

The  Lisp  machine  data  types  are  designed  according  to  these  criteria: 
There  should  be  a wide  variety  of  useful  and  flexible  data  types.  Some  effort 
should  be  made  to  increase  the  bit-efficiency  of  data  representation,  in  order  to 
improve  performance.  The  programmer  should  be  able  to  exercise  control  over  the 
storage  and  representation  of  data,  if  he  wishes.  It  must  always  be  possible  to 
take  an  anonymous  piece  of  data  and  discover  its  type;  this  facilitates  storage 
management.  There  should  be  as  much  type-checking  and  error-checking  as  feasible 
in  the  system. 

Symbols  are  stored  as  four  consecutive  words,  each  of  which  contains  ono 
object.  The  words  are  termed  the  PRINT  NAME  cell,  the  VALUE  cell,  the  FUNCTION 
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cell,  and  the  PROPERTY  LIST  cell.  The  PRINT  NAME  cell  holds  a string  object, 
which  is  the  printed  representation  of  the  symbol.  The  PROPERTY  LIST  cell,  of 
course,  contains  the  property  list,  and  the  VALUE  CELL  contains  the  current  value 
of  the  symbol  (it  is  a shallow-binding  systea).  The  FUNCTION  cell  replaces  the 
task  of  the  EXPR,  SUBR,  FEXPR,  MACRO,  etc.  properties  in  Maclisp.  When  a fora 
such  as  (FOO  ARG1  ARGZ)  is  evaluated,  the  object  in  FOO's  function  cell  is 
applied  to  the  arguaents.  A symbol  object  has  datatype  DTP-SYMBOL,  and  the 
pointer  is  the  address  of  these  four  words. 

Storage  of  list  structure  is  sonewhat  more  complicated.  Normally  a "list 
object”  has  datatype  DTP-LIST,  and  the  pointer  is  the  address  of  a two  word 
block;  the  first  word  contains  the  CAR,  and  the  second  the  CDR  of  the  node. 

However,  note  that  since  a Lisp  object  is  only  29  bits  (24  bits  of 
pointer  and  5 bits  of  data-type),  there  are  three  remaining  bits  in  each  word. 
TWo  of  these  bits  are  termed  the  CDR-CODE  field,  and  are  used  to  compress  the 
storage  requirement  of  list  structure.  The  four  possible  values  of  the  CDR-CODE 
field  are  given  the  symbolic  names  CDR-NORMAL,  CDR-ERROR,  CDR-NEXT,  and  CDR-NIL. 
CDR-NORMAL  indicates  the  two-word  block  described  above.  CDR-NEXT  and  CDR-NIL 
are  used  to  represent  a list  as  a vector,  taking  only  half  as  much  storage  as 
usual;  only  the  CARs  are  stored.  The  CDR  of  each  location  is  simply  the  next 
location,  except  for  the  last,  whose  CDR  is  NIL.  The  primitive  functions  which 
create  lists  (LIST,  APPEND,  etc.)  create  these  compressed  lists.  If  RPLACD  is 
done  on  such  a list,  it  is  automatically  changed  back  to  the  conventional 
two-word  representation,  in  a transparent  way. 

The  idea  is  that  in  the  first  word  of  a list  node  the  CAR  is  represented 
by  29  bits,  and  the  CDR  is  represented  by  2 bits.  It  is  a compressed  pointer 
which  can  take  on  only  3 legal  values:  to  the  symbol  NIL,  to  the  next  location 
after  the  one  it  appears  in,  or  indirect  through  the  next  location.  CDR-ERROR  is 
used  for  words  whose  address  should  not  ever  be  in  a list  object;  in  a "full 
node",  the  first  word  is  CDR-NORMAL,  and  the  second  is  CDR-ERROR.  It  is 
Important  to  note  that  the  cdr-code  portion  of  a word  is  used  in  a different  way 


from  the  data-type  and  pointer  portion;  it  is  a property  of  the  memory  cell 
Itself,  not  of  the  cell's  contents.  A "list  object"  which  is  represented  in 
compressed  form  still  has  data  type  DTP-LIST,  but  the  cdr  code  of  the  word 
addressed  by  its  pointer  field  is  CDR-NEXT  or  CDR-NIL  rather  than  CDR-NORMAL. 

Number  objects  may  have  any  of  three  datatypes.  "FIXNP'^s",  which  are 
24-bit  signed  integers,  are  represented  by  objects  of  datatype  DTP-FIX,  whose 
"pointer"  parts  are  actually  the  value  of  the  number.  Thus  flxnums,  unlike  all 
other  objects,  do  not  require  any  "CONS"ed  storage  for  their  representation. 
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This  speeds  up  arithmetic  programs  when  the  numbers  they  work  with  are  reasonably 
small.  Other  types  of  numbers,  such  as  floating  point,  BIGNUHs  (integers  of 
arbitrarily  high  precision),  complex  numbers,  and  so  on,  are  represented  by 
objects  of  datatype  DTP-EXTENDED-NUHBER  which  point  to  a block  of  storage 
containing  the  details  of  the  number.  The  microcode  automatically  converts 
between  the  different  number  representations  as  necessary,  without  the  need  for 
explicit  declarations  on  the  prograner's  part. 

There  is  also  a datatype  DTP-PDL-NUHBER,  which  is  almost  the  same  as 
DTP-EXTENDED-NUNBER.  The  difference  is  that  pdl  numbers  can  only  exist  in  the 
pdl  buffer  (a  memory  internal  to  the  machine  which  holds  the  most  recent  stack 
frames),  and  their  blocks  of  storage  are  allocated  in  a special  area.  Whenever 
an  object  is  stored  into  memory,  if  it  is  a pdl  number  its  block  of  storage  is 
copied,  and  an  ordinary  extended  number  is  substituted.  The  idea  of  this  is  to 
prevent  intermediate  numeric  results  from  using  up  storage  and  causing  increased 
need  for  garbage  collection.  When  the  special  pdl  number  area  becomes  full,  all 
pdl  numbers  can  quickly  be  found  by  scanning  the  pdl  buffer.  Once  they  have  been 
copied  out  into  ordinary  numbers,  the  special  area  is  guaranteed  empty  and  can  be 
reclaimed,  with  no  need  to  garbage  collect  nor  to  look  at  other  parts  of  memory. 
Note  that  these  are  not  at  all  the  same  as  pdl  numbers  in  Maclisp;  however,  they 
both  exist  for  the  same  reason. 

The  most  important  other  data  type  is  the  array.  Some  problems  are  best 
attacked  using  data  structures  organized  in  the  list-processing  style  of  Lisp, 
and  some  are  best  attacked  using  the  array-processing  style  of  Fortran.  The 
complete  programming  system  needs  both.  As  mentioned  above,  Lisp  Machine  arrays 
are  augmented  beyond  traditional  Lisp  arrays  in  several  ways.  First  of  all,  we 
have  the  ordinary  arrays  of  Lisp  objects,  with  one  or  more  dimensions.  Compact 
storage  of  positive  Integers,  which  may  represent  characters  or  other  non-numeric 
entities,  is  afforded  by  arrays  of  1-blt,  2-bit,  4-bit,  8-blt,  or  16-bit 
elements . 

For  string-processing,  there  are  string-arrays,  which  are  usually 
one-dimensional  and  have  8-blt  characters  as  elements.  At  the  microcode  level 
strings  are  treated  the  same  as  8-bit  arrays,  however  strings  are  treated 
differently  by  READ,  PRINT,  EVAL,  and  many  other  system  and  user  functions.  For 
example,  they  print  out  as  a sequence  of  characters  enclosed  in  quotes.  The 
characters  in  a character  string  can  be  accessed  and  modified  with  the  same 
array-referencing  functions  as  one  uses  for  any  other  type  of  array.  Unlike 
arrays  in  other  Lisp  systems,  Lisp  machine  arrays  usually  have  only  a single  word 
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of  overhead,  so  the  character  strings  are  quite  storage-efficient. 

There  are  a number  of  specialized  types  of  arrays  which  are  used  to 
implement  other  data  types,  such  as  stack  groups,  internal  system  tables,  and, 
most  importantly,  the  refresh  memory  of  the  TV  display  as  a two-dimensional  array 
of  bits. 

An  important  additional  feature  of  Lisp  machine  arrays  is  called  "array 
leaders."  A leader  is  a vector  of  Lisp  objects,  of  user-specified  size,  which 
may  be  tacked  on  to  an  array.  Leaders  are  a good  place  to  remember  miscellaneous 
extra  information  associated  with  an  array.  Many  data  structures  consist  of  a 
combination  of  an  array  and  a record  (see  below);  the  array  contains  a number  of 
objects  all  of  the  same  conceptual  type,  while  the  record  contains  miscellaneous 
items  all  of  different  conceptual  types.  By  storing  the  record  in  the  leader  of 
the  array,  the  single  conceptual  data  structure  is  represented  by  a single  actual 
object.  Many  data  structures  in  Lisp-machine  system  programs  work  this  way. 

Another  thing  that  leaders  are  used  for  is  remembering  the  "current 
length"  of  a partially-populated  array.  By  convention,  array  leader  element 
number  0 is  always  used  for  this. 

Many  programs  use  data  objects  structured  as  "records";  that  is,  a 
compound  object  consisting  of  a fixed  number  of  named  sub-objects.  To  facilitate 
the  use  of  records,  the  Lisp  machine  system  Includes  a standard  set  of  macros  for 
defining,  creating,  and  accessing  record  structures.  The  user  can  choose  whether 
the  actual  representation  is  to  be  a Lisp  list,  an  array,  or  an  array-leader. 
Because  this  is  done  with  macros,  which  translate  record  operations  into  the 
lower-level  operations  of  basic  Lisp,  no  other  part  of  the  system  needs  to  know 
about  records. 

Since  the  reader  and  printer  are  written  in  Lisp  and  user-modifiable, 
this  record-structure  feature  could  easily  be  expanded  into  a full-fledged 
user-defined  data  type  facility  by  modifying  read  and  print  to  support  input  and 
output  of  record  types. 

Another  data  type  is  the  "locative  pointer."  This  is  an  actual  pointer 
to  a memory  location,  used  by  low-level  system  programs  which  need  to  deal  with 
the  guts  of  data  representation.  Taking  CAR  or  CDR  of  a locative  gets  the 
contents  of  the  polnted-to  location,  and  RPLACA  or  RPLACD  stores.  It  is  possible 
to  LANBDA-bind  the  location.  Because  of  the  tagged  architecture  and 
highly-organized  storage,  it  is  possible  to  have  a locative  pointer  into  the 
middle  of  almost  anything  without  causing  trouble  with  the  garbage  collector. 
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REPRESENTATION  OF  PROGRAMS. 

In  the  Lisp  Machine  there  ere  three  representations  for  progress. 
Interpreted  Lisp  code  Is  the  slowest,  but  the  easiest  for  progress  to  understand 
and  sodlfy.  It  can  be  used  for  functions  which  are  being  debugged,  for  functions 
which  need  to  be  understood  by  other  functions,  and  for  functions  which  are  not 
worth  the  bother  of  cospiling.  A few  functions,  notably  EVAL,  will  not  work 
Interpreted. 

Cosplled  Lisp  ( "macrocode* ) is  the  sain  representation  for  progress. 
This  consists  of  instructions  in  a somewhat  conventional  machine-language,  whose 
unusual  features  will  be  described  below.  Unlike  the  case  in  many  other  Lisp 
systems,  aacrocode  progress  still  have  full  checking  for  unbound  variables,  data 
type  errors,  wrong  number  of  argunents  to  a function,  and  so  forth,  so  it  Is  not 
necessary  to  resort  to  interpreted  code  just  to  get  extra  checking  to  detect 
bugs.  Often,  after  typing  In  a function  to  the  editor,  one  skips  the 
interpretation  step  and  requests  the  editor  to  call  the  cospiler  on  It,  which 
only  takes  a few  seconds  since  the  cospiler  is  always  in  the  sachlne  and  only  has 
to  be  paged  in. 

Compiled  code  on  the  Lisp  Machine  is  stored  inside  objects  called  (for 
historical  reasons)  Function  Entry  Frames  (FEFs).  For  each  function  compiled, 
one  FEF  is  created,  and  an  object  of  type  DTP-FEF-POINTER  is  stored  in  the 
function  cell  of  the  symbol  which  is  the  name  of  the  function.  A FEF  consists  of 
some  header  information,  a description  of  the  arguments  accepted  by  the  function, 
pointers  to  external  Lisp  objects  needed  by  the  function  (such  as  constants  and 
special  variables),  and  the  macrocode  which  implements  the  function. 

The  third  form  of  program  representation  is  microcode.  The  system 
includes  a good  deal  of  hand-coded  microcode  which  executes  the  macrocode 
instructions,  implements  the  data  types  and  the  function-calling  mechaniss, 
maintains  the  paged  virtual  memory,  does  storage  allocation  and  garbage 
collection,  and  performs  similar  systemic  functions.  The  primitive  operations  on 
the  basic  data  types,  that  is,  CAR  and  CDR  for  lists,  arithmetic  for  numbers, 
reference  and  store  for  arrays,  etc.  are  implemented  as  microcode  subroutines. 
In  addition,  a number  of  commonly-used  Lisp  functions,  for  instance  GET  and  ASSQ, 
are  hand-coded  in  microcode  for  speed. 

In  addition  to  this  system-supplied  microcode,  there  is  a feature  called 
slcro  compilation.  Because  of  the  simplicity  and  generality  of  the  CONS 
slcroprocessor,  it  is  feasible  to  write  a cospiler  to  compile  user-written  Lisp 
functions  directly  into  microcode,  eliminating  the  overhead  of  fetching  and 
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interpreting  macroinstructions.  This  can  be  used  to  boost  performance  by 
microcompiling  the  most  critical  routines  of  a program.  Because  it  is  done  by  a 
compiler  rather  than  a system  programmer,  this  performance  Improvement  is 
available  to  everyone.  The  amount  of  speedup  to  be  expected  depends  on  the 
operations  used  by  the  program;  simple  low-level  operations  such  as  data 
transmission,  byte  extraction,  integer  arithmetic,  and  simple  branching  can 
expect  to  benefit  the  most.  Function  calling,  and  operations  which  already  spend 
most  of  their  time  in  microcode,  such  as  A88Q,  will  benefit  the  least.  In  the 
best  case  one  can  achieve  a factor  of  about  20.  In  the  worst  case,  maybe  no 
speedup  at  all. 

Since  the  amount  of  control  memory  is  limited,  only  a small  number  of 
microcompiled  functions  can  be  loaded  in  at  one  time.  This  means  that  programs 
have  to  be  characterised  by  spending  most  of  their  time  in  a small  inner  kernel 
of  functions  in  order  to  benefit  from  mlcrocompilatlon;  this  is  probably  true  of 
most  programs.  There  will  be  fairly  hairy  metering  facilities  for  identifying 
such  critical  functions. 

We  do  not  yet  have  a microcompiler,  but  a prototype  of  one  was  written 
and  heavily  used  as  part  of  the  Lisp  machine  simulator.  It  compiles  for  the 
PDP-10  rather  than  CONS,  but  uses  similar  techniques  and  a similar  Interface  to 
the  built-in  microcode. 

In  all  three  forms  of  program,  the  flexibility  of  function  calling  is 
augmented  with  generalized  LAHBDA-lists.  In  order  to  provide  a more  general  and 
flexible  scheme  to  replace  EXPRs  vs.  FEXPRs  vs.  LEXPRs,  a syntax  borrowed  from 
Huddle  and  Conniver  is  used  in  LAMBDA  lists.  In  the  general  case,  there  are  an 
arbitrary  number  of  REQUIRED  parameters,  followed  by  an  arbitrary  number  of 
OPTIONAL  parameters,  possibly  followed  by  one  REST  parameter.  When  a function  is 
APPLIED  to  its  arguments,  first  of  all  the  required  formal  parameters  are  paired 
off  with  arguments;  if  there  are  fewer  arguments  than  required  parameters,  an 
error  condition  is  caused.  Then,  any  remaining  arguments  are  paired  off  with  the 
optional  parameters;  if  there  are  more  optional  parameters  than  arguments 
remaining,  then  the  rest  of  the  optional  parameters  are  initialized  in  a 
user-specified  manner.  The  REST  parameter  is  bound  to  a list,  possibly  NIL,  of 
all  arguments  remaining  after  all  OPTIONAL  parameters  k.e  bound.  To  avoid 
CONSlng,  this  list  is  actually  stored  on  the  pdl;  this  means  that  you  have  to  be 
careful  how  you  use  it,  unfortunately.  It  is  also  possible  to  control  which 
arguments  are  evaluated  and  which  are  quoted. 

Normally,  such  a complicated  calling  sequence  would  ontail  an 
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unacceptable  anount  of  overhead.  Because  this  Is  all  iapleaented  by  Microcode, 
and  because  the  staple,  coanon  cases  are  special-cased,  we  can  provide  these 
advanced  features  and  still  retain  the  efficiency  needed  in  a practical  system. 

We  will  now  discuss  soae  of  the  Issues  in  the  design  of  the  macrocode 
instruction  set.  Each  macroinstruction  is  IB  bits  long;  they  are  stored  two  per 
word.  The  instructions  work  in  a stack-oriented  machine.  The  stack  is  formatted 
into  frames;  each  frame  contains  a bunch  of  arguments,  a bunch  of  local  variable 
value  slots,  a push-down  stack  for  intermediate  results,  and  a header  which  gives 
the  function  which  owns  the  frame,  links  this  frame  to  previous  frames,  remembers 
the  program  counter  and  flags  when  this  frame  is  not  executing,  and  may  contain 
"additional  information"  used  for  certain  esoteric  purposes.  Originally  this  was 
intended  to  be  a spaghetti  stack,  but  the  invention  of  closures  and  stack-groups 
(see  the  control-structure  section),  combined  with  the  extreme  complexity  of 
spaghetti  stacks,  made  us  decide  to  use  a simple  linear  stack.  The  current  frame 
is  always  held  in  the  pdl  buffer,  so  accesses  to  arguments  and  local  variables  do 
not  require  memory  references,  and  do  not  have  to  make  checks  related  to  the 
garbage  collector,  which  improves  performance.  Usually  several  other  frames  will 
also  be  in  the  pdl  buffer. 

The  macro  instruction  set  Is  bit-compact.  The  stack  organization  and 
Lisp's  division  of  programs  into  small,  separate  functions  means  that  address 
fields  can  be  small.  The  use  of  tagged  data  types,  powerful  generic  operations, 
and  easily-called  aicrocoded  functions  makes  a single  IB-bit  macro  instruction  do 
the  work  of  several  instructions  on  a conventional  machine  such  as  a PDP-10. 

The  primitive  operations  which  are  the  instructions  which  the  compiler 
generates  are  higher-level  than  the  instructions  of  a conventional  machine.  They 
all  do  data  type  checks;  this  provides  more  run-time  error  checking  than  in 
Maclisp,  which  increases  reliability.  But  it  also  eliminates  much  of  the  need  to 
make  declarations  in  order  to  get  efficient  code.  Since  a data  type  check  is 
being  made,  the  "primitive"  operations  can  dynamically  decide  which  specific 
routine  is  to  be  called.  This  means  that  they  are  all  "generic",  that  is,  they 
work  for  all  data  types  where  they  make  sense. 

The  operations  which  are  regarded  as  most  important,  and  hence  are 
easiest  for  macrocode  to  do,  are  data  transmission,  function  calling,  conditional 
testing,  and  simple  operations  on  primitive  types,  that  is,  CAR,  CDR,  CADR,  CDDR, 
RPLACA,  and  RPLACD,  plus  the  usual  arithmetic  operations  and  comparisons.  More 
complex  operations  are  generally  done  by  "miscellaneous"  instructions,  which  call 
microcoded  subroutines,  passing  arguments  on  the  temporary-results  stack. 

There  are  three  main  kinds  of  addressing  in  macrocode.  First,  there  is 
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lapllclt  addressing  of  the  top  of  the  stack.  This  is  the  usual  way  that  operands 
get  froa  one  Instruction  to  the  next. 

Second,  there  is  the  source  field  (this  is  sometimes  used  to  store 
results,  but  I will  call  it  a source  anyway).  The  source  can  address  any  of  the 
following:  Up  to  64  arguaents  to  the  current  function.  Up  to  64  local  variables 
of  the  current  function.  The  last  result,  popped  off  the  stack.  One  of  several 
commonly-used  constants  (e.g.  NIL)  stored  in  a systea-wlde  constants  area.  A 
constant  stored  in  the  FEF  of  this  function.  A value  cell  or  a function  cell  of 
a symbol,  referenced  by  aeans  of  an  invisible  pointer  in  the  FEF;  this  mode  is 
used  to  reference  special  variables  and  to  call  other  functions. 

Third,  there  is  the  destination  field,  which  specifies  what  to  do  with 
the  result  of  the  instruction.  The  possibilities  are:  Ignore  it,  except  set  the 
indicators  used  by  conditional  branches.  Push  it  on  the  stack.  Pass  it  as  an 
argument.  Return  it  as  the  value  of  this  function.  Cons  up  a list. 

There  are  five  types  of  macroinstructions,  which  will  be  described. 
First,  there  are  the  data  transmission  instructions,  which  take  the  source  and 
HOVE  it  to  the  destination,  optionally  taking  CAR,  CDR,  CAAR,  CADR,  CDAR,  or  CDDR 
in  the  process.  Because  of  the  powerful  operations  that  can  be  specified  in  the 
destination,  these  instructions  also  serve  as  argument-passing,  function-exiting, 
end  list-making  instructions. 

Next  we  have  the  function  calling  instructions.  The  simpler  of  the  two 
is  CALLO,  call  with  no  arguments.  It  calls  the  function  indicated  by  its  source, 
and  when  that  function  returns,  the  result  is  stored  in  the  destination.  The 
microcode  takes  care  of  Identifying  what  type  of  function  is  being  called. 
Invoking  it  in  the  appropriate  way,  and  saving  the  state  of  the  current  function. 
It  traps  to  the  interpreter  if  the  called  function  is  not  compiled. 

The  more  complex  function  call  occurs  when  there  are  arguments  to  be 
passed.  The  way  it  works  is  as  follows.  First,  a CALL  instruction  is  executed. 
The  source  operand  is  the  function  to  be  called.  The  beginnings  of  a new  steck 
frame  are  constructed  at  the  end  of  the  current  frame,  and  the  function  to  be 
called  is  remembered.  The  destination  of  the  CALL  instruction  specifies  where 
the  result  of  the  function  will  be  placed,  and  it  is  saved  for  later  use  when  the 
function  returns.  Next,  instructions  ere  executed  to  compute  the  arguments  and 
store  them  into  the  destination  NEXT-ARGUMENT.  This  causes  them  to  be  added  to 
the  new  stack  frame.  When  the  last  argument  is  computed,  it  is  stored  into  the 
destination  LAST- ARGUMENT,  which  stores  it  in  the  new  steck  frame  and  then 
activates  the  call.  The  function  to  be  called  is  anelysed,  and  the  erguments  are 
bound  to  the  formal  parameters  (usually  the  erguments  ere  alreedy  in  the  correct 
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slots  of  tha  new  stack  fraas).  Bacausa  tha  computation  of  ths  arguments  Is 
lntroducad  by  a CALL  Instruction.  It  is  oasy  to  find  out  idiaro  tha  arguaonts  aro 
and  how  many  thara  ara.  Tha  now  stack  fraas  bscoass  currant  and  that  function 
bogins  axacution.  Whan  it  returns,  tha  saved  destination  of  tha  CALL  instruction 
is  ratr laved  and  tha  result  is  stored.  Note  that  by  using  a destination  of 
NEXT-ARGUMENT  or  LAST-ARGUMENT  function  calls  any  bo  nested.  By  using  a 
destination  of  RETURN  tha  result  of  one  function  any  becoae  tha  result  of  Its 
caller. 

The  third  class  of  aacro  instructions  consists  of  a nuabar  of  coaaon 
operations  on  prlaitive  $J*ta  types.  These  instructions  do  not  have  an  explicit 
destination,  in  order  to  save  bits,  but  lapllcltly  push  their  result  (if  any) 

onto  the  stack.  This  sonatinas  necessitates  the  generation  of  an  oxtra  MOVE 

( 

instruction  to  put  the  result  where  it  was  really  wanted.  These  Instructions 
Include:  Operations  to  store  results  froa  the  pdl  into  the  "source".  The  basic 
arithmetic  and  bitwise  boolean  operations.  Coaparlson  operations,  including  EQ 
and  arithaetic  coaparlson,  which  set  the  indicators  for  use  by  conditional 
branches.  Instructions  which  set  the  "source"  operand  to  NIL  or  xero.  Iteration 
instructions  which  change  the  "source"  operand  using  COR,  CDOR,  1*.  or  1-  (add  or 
subtract  one).  Binding  instructions  which  laabda-hlnd  the  "source"  operand,  then 
optionally  set  it  to  NIL  or  to  a value  popped  off  the  stack.  And,  finally,  an 
instruction  to  push  its  effective  address  on  the  stack,  as  a locative  pointer. 

The  fourth  class  of  aacro  instructions  are  the  branches,  which  serve 
aalnly  for  compiling  COND.  Branches  contain  a self-relative  address  which  is 
transferred  to  if  a specified  condition  is  satisfied.  There  are  two  indicators, 
which  tell  if  the  last  result  was  NIL,  and  if  it  was  an  atoa,  and  the  state  of 
these  indicators  can  be  branched  on;  there  is  also  an  unconditional  branch,  of 
course.  For  branches  aore  than  256  half-words  away,  there  is  a double-length 
long-branch  Instruction.  An  interesting  fact  is  that  there  are  not  really  any 
indicators;  it  turns  out  to  be  faster  just  to  save  the  last  result  in  its 
entirety,  and  compare  it  against  NIL  or  whatever  when  that  is  needed  by  a branch 
instruction.  It  only  has  to  be  saved  froa  one  instruction  to  the  immediately 
following  one. 

The  fifth  class  of  macro  Instructions  is  the  "miscellaneous  function." 
This  selects  one  of  512  aicrocoded  functions  to  be  called,  with  arguments  taken 
froa  results  previously  pushed  on  the  stack.  A destination  is  specified  to 
receive  the  result  of  the  function.  In  addition  to  conaonly-used  functions  such 
as  GET,  CONS,  CDDDDR,  REMAINDER,  and  A MQ,  miscellaneous  functions  Include 
sub-prlaitlves  (discussed  above),  and  instructions  which  are  not  as  commonly  used 
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as  the  first  four  classes,  including  operations  such  as  array-accessing,  consing 
up  lists,  un-laabda-binding,  special  funny  types  of  function  calling,  etc. 

The  way  consing-up  of  lists  works  is  that  one  first  does  a Miscellaneous 
function  saying  "sake  a list  N long*.  One  then  executes  N instructions  with 
destination  NEXT-LIST  to  supply  the  elements  of  the  list.  After  the  Nth  such 
instruction,  the  list-object  Magically  appears  on  the  top  of  the  stack.  This 
saves  having  to  Make  a call  to  the  function  LIST  with  a variable  nuMber  of 
arguMents . 

Another  type  of  "instruction  set"  used  with  Macrocode  is  the  ArguMent 
Description  List,  which  is  executed  by  a different  Mlcrocoded  interpreter  at  the 
tlMe  a function  is  entered.  The  ADL  contains  one  entry  for  each  argunent  which 
the  function  expects  to  be  passed,  and  for  each  auxiliary  variable.  It  contains 
all  relevant  inforaation  about  the  argunent:  whether  it  is  required,  optional, 
or  rest,  how  to  initialize  it  if  it  is  not  provided,  whether  it  is  local  or 
special,  datatype  checking  inforaation,  and  so  on.  Sonatinas  the  ADL  can  be 
dispensed  with  if  the  "fast  argunent  option"  can  be  used  Instead;  this  helps 
save  tine  and  nenory  for  snail,  siaple  functions.  The  fast-arguaent  option  is 
used  when  the  optional  argunents  and  local  variables  are  all  to  be  initialized  to 
NIL,  there  are  not  too  Many  of  then,  there  is  no  date-type  checking,  and  the 
usage  of  special  variables  is  not  too  coapllcated.  The  selection  of  the 
fast-arguaent  option,  if  appropriate,  is  automatically  made  by  the  systea,  so  the 
user  need  not  be  concerned  with  it.  The  details  can  be  found  in  the  FORMAT 
document. 
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CONTROL  STRUCTURES. 
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Function  calling.  Function  calling  is,  of  course,  the  basic  main  control 
structure  in  Lisp.  As  Mentioned  above.  Lisp  Machine  function  calling  is  aade 
fast  through  the  use  of  Microcode  and  augmented  with  optional  arguments , rest 
argueMnts,  Multiple  return  values,  and  optional  type-checking  of  arguments. 

CATCH  and  THROW.  CATCH  and  THROW  are  a Maclisp  control  structure  which 
will  be  Mentioned  here  since  they  aay  be  new  to  soae  people.  CATCH  is  a way  of 
Marking  a particular  point  in  the  stack  of  recursive  function  invocations.  THROW 
causes  contrel  to  be  unwound  to  the  Matching  CATCH,  automatically  returning 
through  the  intervening  function  calls.  They  are  used  aainly  for  handling  errors 
and  unusual  conditions.  They  are  also  useful  for  getting  out  of  a hairy  piece  of 


; ^ ippfft., 


LISP  Machine 


19 


Progress  Report 


code  when  It  has  discovered  whet  value  it  wants  to  return;  this  applies 
particularly  to  nested  loops. 

Closures.  The  LISP  Mchlne  contains  a date-type  called  "closure"  which 
is  used  to  implement  "full  funarglng*.  By  turning  a function  into  a closure,  it 
becomes  possible  to  pass  it  as  an  argument  with  no  worry  about  naming  conflicts, 
and  to  return  it  as  a value  with  exactly  the  minimum  necessary  amount  of  binding 
environment  being  retained,  solving  the  classical  "funarg  problem".  Closures  are 
implemented  in  such  a way  that  when  they  are  not  used  the  highly  spaed-  and 
storage-efficient  shallow  binding  variable  schema  operates  at  full  efficiency, 
and  when  they  are  used  things  are  slowed  down  only  slightly.  The  way  one  creates 
a closure  is  with  a form  such  as: 

(CLOSURE  '(FOO-PARAH  F00- STATE) 

(FUNCTION  FOO-BAR)) 

The  function  could  also  be  written  directly  in  place  as  a 
LANBDA-expression,  instead  of  referring  to  the  externally  defined  FOO-BAR.  The 
variables  F 00 -P ARAM  and  FOO-STATE  are  those  variables  which  are  used  free  by 
FOO-BAR  and  are  Intended  to  be  "closed".  That  is,  these  are  the  variables  whoso 
binding  environment  is  to  be  fixed  to  that  in  effect  at  the  time  the  closure  is 
created.  The  explicit  declaration  of  which  variables  are  to  be  closed  allows  the 
Implementation  to  have  high  efficiency,  since  it  does  not  need  to  save  the  whole 
variable-binding  environment,  almost  all  of  which  is  useless.  It  also  allows  the 
programmer  to  explicitly  choose  for  each  variable  whether  it  is  to  be  dynamically 
bound  (at  the  point  of  call)  or  statically  bound  (at  tha  point  of  creation  of  the 
closure),  a choice  which  is  not  conveniently  available  in  other  languages.  In 
addition  the  program  is  clearer  because  the  intended  effect  of  the  closure  is 
made  manifest  by  listing  the  variables  to  be  affected. 

Here  is  an  example,  in  which  the  closure  feature  is  used  to  solve  a 
problem  presented  in  "LAMBDA  - The  Ultimate  Imperative"  [LAMBDA].  Tha  problem  is 
to  write  a function  called  GENERATE-SQRT-OF -GIVEN- EXTRA- TOLERANCE,  which  is  to 
take  one  argument,  which  is  the  factor  by  which  the  tolerance  is  to  be  Increased, 
and  return  a function  which  takes  square  roots  with  that  much  more  tolerance  than 
usual,  whatever  "usual"  is  later  defined  to  be.  You  are  given  a function  SORT 
which  makes  a free  reference  to  EPSILON,  which  is  tha  toleranca  it  demands  of  the 
trial  solution.  The  reason  this  example  presents  difficulties  to  various 
languages  is  that  the  variable  EPSILON  must  be  bound  at  the  point  of  call  (l.a. 
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function , the  external  valua  cell  pointer  is  saved  away  on  tha  binding  stack, 
like  any  saved  variable  value,  and  the  variable  reverts  to  normal  nonclosed 
status.  When  the  closed  function  returns,  the  bindings  of  the  closed  variables 
are  restored  Just  like  any  other  variables  bound  by  the  function. 

Note  the  economy  of  mechanism.  Almost  all  of  tha  system  is  completely 
unaffected  by  and  unawara  of  the  existence  of  closures;  the  invisible  pointer 
mechanism  takes  care  of  things.  The  retainable  binding  environments  are 
allocated  through  the  standard  CONS  operation.  The  switching  of  variables 
between  normal  and  "closed*  status  is  done  through  the  standard  binding 
operation.  The  operations  used  by  a closed  function  to  access  the  closed 
variables  are  the  same  as  those  used  to  access  ordinary  variables;  closures  are 
called  in  the  same  way  as  ordinary  functions.  Closures  work  just  as  well  in  the 
interpreter  as  in  the  compiler.  An  important  thing  to  note  is  the  minimality  of 
CONSlng  in  closures.  When  a closure  is  created,  some  CONSing  is  done;  external 
value  cells  and  the  closure-object  itself  must  be  created,  but  thore  is  no  extra 
"overhead".  When  a closure  is  called,  no  CONSlng  happens. 

One  thing  to  note  is  that  in  the  compiler  closed  variables  have  to  be 
declared  "special".  This  is  a general  feature  of  the  Maclisp  and  Lisp  machine 
compilers,  that  by  default  variables  are  local,  which  means  that  they  are 
lexically  bound,  only  available  to  the  function  in  which  they  are  bound,  and 
implemented  not  with  atomic  symbols,  but  simply  as  slots  in  the  stack.  Variables 
that  are  declared  special  are  Implemented  with  shallow-bound  atomic  symbols. 
Identical  to  variables  in  the  interpreter,  and  hava  available  either  dynamic 
binding  or  closure  binding.  They  are  somewhat  less  efficient  since  it  takes  two 
memory  references  to  access  them  and  several  to  bind  thorn. 

Stack  groups.  The  stack  group  is  a type  of  Lisp  object  useful  for 
implementation  of  certain  advanced  control  structures  such  as  coroutines, 
asynchronous  processes,  and  ganerators.  A stack  group  is  similar  to  a process 
(or  fork  or  Job  or  task  or  control-point)  in  a time-sharing  system;  it  contains 
such  state  information  as  the  "regular"  and  "special"  (binding)  PDLs  and  various 
Internal  ragisters.  At  all  times  there  is  one  stack  group  running  on  the 
macMne. 

Control  may  be  passed  between  stack  groups  in  sevoral  ways  (not  all  of 
which  exist  yet  on  our  prototype  machine).  A stack-group  may  be  called  like  a 
function;  when  it  wants  to  roturn  it  can  do  a XdTACK-GROUP -RETURN  which  is 
different  from  an  ordinary  function  return  in  that  the  state  of  the  stack  group 
remains  unchanged;  the  next  time  it  is  called  it  picks  up  from  where  it  left 
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eff.  This  is  good  for  generator-like  applications;  each  tine 
XST ACK-GROUP  - RETURN  is  dona,  a value  is  eaitted  froa  the  generator,  and  as  a 
side-effect  execution  is  suspended  until  the  next  tiae  the  generator  is  called. 
XSTACK-GROUP-RETURN  is  analogous  to  the  ADIEU  construct  in  CONNIVER. 

Control  can  siaply  be  passed  explicitly  froa  one  stack  group  to  another, 
coroutine-style.  Alternatively,  there  can  be  a scheduler  stack-group  which 
invokes  other  stack  groups  when  their  requested  scheduling  conditions  are 
satisfied. 

Interrupts  cause  control  of  the  Machine  to  be  transferred  to  an 
interrupt-handler  stack  group.  Essentially  this  is  a forced  stack  group  call 
like  those  calls  described  above.  Slailarly,  when  the  Microcode  detects  an  error 
the  current  stack  group  is  suspended  and  control  is  passed  to  an  error-handling 
stack  group.  The  state  of  the  stack  group  that  got  the  error  is  loft  exactly  as 
it  was  when  the  error  occurred,  undisturbed  by  any  error-handling  operations. 
This  facilitates  error  analysis  and  recovery. 

When  the  Machine  is  started,  an  'initial*  stack  group  becoaes  the  current 
stack  group,  and  is  forced  to  call  the  first  function  of  Lisp. 

Note  that  the  saae  scheduler-driven  stack-group  switching  aechanlsa  can 
be  used  both  for  user  prograas  which  want  to  do  parallel  coaputations,  and  for 
systea  prograaalng  purposes  such  as  the  handling  of  network  servers  and 
peripheral  handlers. 

Each  stack  group  has  a call-state  and  a calling-stack-group  variable, 
which  are  used  in  aaintainlng  the  relations  between  stack  groups.  A stack  group 
also  has  soae  option  flags  controlling  whether  the  systea  tries  to  keep  different 
stack  groups'  binding  envlronaents  distinct  by  undoing  the  special  variable 
bindings  of  the  stack  group  being  left  and  redoing  the  bindings  of  the  stack 
group  being  entered. 

Stack  groups  are  created  with  the  function  MAKE -STACK-GROUP , Which  takes 
one  aain  arguaent,  the  "nane*  of  the  stack  group.  This  is  used  only  for 
debugging,  and  can  be  any  aneaonlc  syabol.  It  returns  the  stack  group,  i.e.,  a 
Lisp  object  with  data  type  DTP-STACK-GROUP.  Optionally  the  sizes  of  the  pdls  aay 
be  specified. 

The  function  STACK-GROUP-PRESET  is  used  to  initialize  the  state  of  a 
stack  group:  the  first  arguaent  is  the  stack  group,  the  second  is  a function  to 
be  called  when  the  stack  group  is  invoked,  and  the  rest  are  arguaents  to  that 
function.  Both  PDLs  are  nade  eapty.  The  stack  group  is  set  to  the 
AWAITING-INITIAL-CALL  state.  When  it  is  activated,  the  specified  function  will 
find  that  it  has  been  called  with  the  specified  erguaents.  If  it  should  return 
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l „ in  the  noraal  way,  (l.e.  the  stack  group  'returns  off  the  top',  the  stack  group 
will  enter  a "used  up”  state  and  control  will  revert  to  the  celling  stack  group. 
Normally,  the  specified  function  will  use  RSTACK-GROUP-RETURN  several  tiaes; 
otherwise  it  Bight  as  well  have  been  called  directly  rather  than  in  a stack 
group . 

One  laportant  difference  between  stack  groups  and  other  aeans  proposed  to 
iapleaent  siailar  features  is  that  the  stack  group  scheae  involves  no  loss  of 
efficiency  in  normal  coaputatlon.  In  fact,  the  coapiler,  the  interpreter,  and 
even  the  runtiae  function-calling  aechanlsa  are  coapletely  unaware  of  the 
existence  of  stack  groups. 


STORAGE  ORGANIZATION. 


Increaental  Garbage  Collection.  The  Lisp  aachlne  will  use  a real-time, 
lncreaental,  compacting  garbage  collector.  Real-tiae  aeans  that  CONS  (or  related 
functions)  never  delay  Lisp  execution  for  aore  than  a saall,  bounded  aaount  of 
tlae. 

This  is  very  important  in  a machine  with  a large  address  space,  where  a 
traditional  garbage  collection  could  bring  everythin?  to  a halt  for  several 
alnutes.  The  garbage  collector  is  incremental,  l.e.  garbage  collection  is 
interleaved  with  execution  of  the  user's  prograa;  every  tlae  you  call  CONS  the 
garbage  collection  proceeds  for  a few  steps.  Copying  can  also  be  triggered  by  a 
aeaory  reference  which  fetches  a pointer  to  data  which  has  not  yet  been  copied. 
The  garbage  collector  coapactifies  in  order  to  improve  the  paging 
characteristics. 

The  basic  algorithm  is  described  in  a paper  by  Henry  Baker  [GC].  We  have 
not  implemented  it  yet,  but  design  is  proceeding  and  aost  of  the  necessary 
changes  to  the  microcode  have  already  been  aade.  It  is  auch  simpler  than 
previous  methods  of  lncreaental  garbage  collection  in  that  only  one  process  is 
needed;  this  avoids  interlocking  and  synchronisation  probleas,  which  are  often 
very  difficult  to  debug. 


Areas.  Storage  in  the  Lisp  aachine  is  divided  into  'areas. ■ Each  area 
contains  related  objects,  of  any  type.  Since  unlike  PDP-10  Lisps  we  do  not 
encode  the  data  type  in  the  address,  we  are  free  to  use  the  address  to  encode  the 
area.  Areas  are  intended  to  give  the  user  control  over  the  paging  behavior  of 
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his  program,  among  other  things.  By  potting  related  data  together,  locality  can 
be  greatly  Increased.  Whenever  a new  object  is  created,  for  instance  with  CONS, 
the  area  to  be  used  can  optionally  be  specified.  There  is  a default  Working 
Storage  area  which  collects  those  objects  which  the  user  has  not  chosen  to 
control  explicitly. 

Areas  also  give  the  user  a handle  to  control  the  garbage  collector . Some 
areas  can  be  declared  to  be  "static”,  which  aeans  that  they  change  slowly  and  the 
garbage  collector  should  not  attempt  to  reclaim  any  space  in  them.  This  can 
eliminate  a lot  of  useless  copying.  All  pointers  out  of  a static  area  can  be 
collected  into  an  "exit  vector",  eliminating  any  need  for  the  garbage  collector 
to  look  at  that  area.  As  an  important  example,  an  English-language  dictionary 
can  be  kept  inside  the  Lisp  without  adversely  affecting  the  speed  of  garbage 
collection.  A "static"  area  can  be  explicitly  garbage-collected  at  infrequent 
intervals  when  it  is  believed  that  that  night  be  worthwhile. 

Each  area  can  potentially  have  a different  storage  discipline,  a 
different  paging  algorithm,  and  even  a different  data  representation.  The 
microcode  will  dispatch  on  an  attribute  of  the  area  at  the  appropriate  times. 
The  structure  of  the  machine  makes  the  performance  cost  of  these  features 
negligible;  information  about  areas  is  stored  in  extra  bits  in  the  memory 
mapping  hardware  where  it  can  be  quickly  dispatched  on  by  the  microcode.  These 
dispatches  usually  have  to  be  done  anyway  to  make  the  garbage  collector  work,  and 
to  implement  invisible  pointers. 

Invisible  Pointers.  An  invisible  pointer  is  similar  to  an  Indirect 
address  word  on  a conventional  computer  except  the  indirection  is  specified  in 
the  data  instead  of  in  the  instruction.  A reference  to  a memory  location 
containing  an  invisible  pointer  is  automatically  altered  to  use  the  location 
pointed  to  by  the  invisible  pointer.  The  term  "Invisible"  refers  to  the  fact 
that  the  presence  of  such  pointers  is  not  visible  to  most  of  the  system,  since 
they  are  handled  by  the  lowest-level  memory-referencing  operations.  The 
invisible  pointer  feature  does  not  slow  anything  down  too  much,  because  it  is 
part  of  the  data  type  checking  that  is  done  anyway  (this  is  one  of  the  benefits 
of  a tagged  architecture).  A number  of  advanced  features  of  the  Lisp  machine 
depend  upon  invisible  pointers  for  their  efficient  implementation. 

Closures  use  invisible  pointers  to  connect  Internal  value  cells  to 
external  value  cells.  This  allows  the  variable  binding  scheme  to  be  altered  from 
normal  shallow  binding  to  allocated-value-cell  shallow  binding  when  closures  are 
being  used,  without  altering  the  normal  operation  of  the  machine  when  closures 
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are  not  being  used.  At  the  seae  tiae  the  slow-down  when  closures  are  used 
amounts  to  only  2 aicroseconds  per  closed-variable  reference,  the  tiae  needed  to 
detect  and  follow  the  invisible  pointer. 

Invisible  pointers  are  necessary  to  the  operation  of  the  cdr-coded 
compressed  list  scheae.  If  an  RPLACD  is  done  to  a compressed  list,  the  list  can 
no  longer  be  represented  in  the  coapressed  fora.  It  is  necessary  to  allocate  a 
full  2-word  cons  node  and  use  that  in  its  place.  But,  it  is  also  necessary  to 
preserve  the  identity  (with  respect  to  EQ)  of  the  list.  This  is  done  by  storing 
an  invisible  pointer  in  the  original  location  of  the  coapressed  list,  pointing  to 
the  uncompressed  copy.  Then  the  list  is  still  represented  by  its  original 
location,  preserving  EQ-ness,  but  the  CAR  and  CDR  operations  follow  the  invisible 
pointer  to  the  new  location  and  find  the  proper  car  and  cdr. 

This  is  a special  case  of  the  aore  general  use  of  invisible  pointers  for 
"forwarding"  references  from  an  old  representation  of  an  object  to  a new  one. 
For  instance,  there  is  a function  to  increase  the  size  of  an  array.  If  it  cannot 
do  it  in  place,  it  makes  a new  copy  and  leaves  behind  an  Invisible  pointer. 

The  exit-vector  feature  uses  invisible  pointers.  One  may  set  up  an  area 
to  have  the  property  that  all  references  from  inside  that  area  to  objects  in 
other  areas  are  collected  into  a single  exit-vector.  A location  which  would 
normally  contain  such  a reference  instead  contains  an  Invisible  pointer  to  the 
appropriate  slot  in  the  exit  vector.  Operations  on  this  area  all  work  as  before, 
except  for  a slight  slow-down  caused  by  the  invisible  pointer  following.  It  is 
also  desirable  to  have  automatic  checking  to  prevent  the  creetion  of  new  outside 
references;  when  an  attempt  is  made  to  store  an  outside  object  into  this  area 
execution  can  trap  to  a routir.s  which  creates  a new  exit  vector  entry  if 
necessary  and  stores  an  invisible  pointer  instead.  The  reason  for  exit  vectors 
is  to  speed  up  garbage  collection  by  eliminating  the  need  to  swap  in  all  of  the 
pages  of  the  area  in  order  to  find  and  relocate  all  its  references  to  outside 
objects. 

The  macrocode  instruction  set  relies  on  invisible  pointers  in  order  to 
access  the  value  cells  of  "special"  (non-local)  variables  and  the  function  cells 
of  functions  to  be  called. 

Certeln  system  variables  stored  in  the  microcode  scratchpad  memory  are 
made  available  to  Lisp  programs  by  linking  the  value  cells  of  appropriately-named 
Lisp  symbols  to  the  scratchpad  memory  locations  with  invisible  pointers.  This 
makes  it  possible  not  only  to  reed  and  write  these  variebles,  but  also  to 
lambda-bind  them.  In  a similar  fashion,  invisible  pointers  could  be  used  to  link 
two  symbols'  value  cells  together,  in  the  fashion  of  HicroPlannar  but  with  much 
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THE  EDITORS 

The  Lisp  Machine  systee  includes  an  advanced  real-time  display  oriented 
editor,  which  is  written  completely  in  Lisp.  The  design  of  this  editor  drew 
heavily  on  our  experience  with  the  EHACS  editor  (and  its  predecessors)  on  the 
PDP-10 . The  high-speed  display  and  fast  response  tine  of  the  Lisp  machine  are 
crucial  to  the  success  of  the  editor. 

The  TV  display  is  used  to  show  a section  of  the  text  buffer  currently 
being  edited.  When  the  user  types  a normal  printing  character  on  the  keyboard, 
that  character  is  Inserted  into  his  buffer,  and  the  display  of  the  buffer  is 
updated;  you  see  the  text  as  you  type  it  in.  When  using  an  editor,  most  of  the 
user's  time  is  spent  in  typing  in  text;  therefore,  this  is  made  as  easy  as 
possible.  Editing  operations  other  than  the  insertion  of  single  characters  are 
Invoked  by  control-keys,  l.e.  by  depressing  the  CONTROL  and/or  META  shift  keys, 
•long  with  a single  character.  For  example,  the  command  to  move  the  current 
location  for  typeln  in  the  buffer  (the  "point")  backward  is  Control-B  (B  is 
mnemonic  for  Backward);  the  command  to  move  to  the  next  line  is  Control-N. 
There  are  many  more  advanced  commands,  which  know  how  to  Interpret  the  text  as 
words  or  as  the  printed  representation  of  Lisp  data  structure;  Neta-F  moves 
forward  over  an  English  word,  and  Control-Heta-F  moves  forward  over  a Lisp 
expression  (an  atom  or  a list). 

The  real-time  display-oriented  type  of  editor  is  much  easier  to  use  than 
traditional  text  editors,  because  you  can  always  see  exactly  what  you  are  doing. 
A new  user  can  sit  right  down  and  type  in  text.  However,  this  does  not  mean  that 
there  can  be  no  sophisticated  coemands  and  macros.  Very  powerful  operations  are 
provided  in  the  Lisp  machine  editor.  Self-documentation  features  exist  to  allow 
the  user  to  ask  what  a particular  key  does  before  trying  it,  and  to  ask  what  keys 
contain  a given  word  in  their  description.  Users  can  write  additional  commands. 
In  Lisp,  and  add  them  to  the  editor's  command  tables. 

The  editor  knows  how  much  a line  should  be  indented  in  a Lisp  program  in 
order  to  reflect  the  level  of  syntactic  nesting.  When  typing  in  Lisp  code,  one 
uses  the  Linefeed  key  after  typing  in  a line  to  move  to  the  next  line  and 
automatically  Indent  it  by  the  right  amount.  This  serves  the  additional  purpose 
of  Instantly  pointing  out  errors  in  numbers  of  parentheses. 
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The  editor  can  ba  used  as  a front  and  to  the  Lisp  top  level  loop.  This 
provides  what  can  ba  thought  of  as  vary  sophisticated  rubout  processing.  Whan 
the  user  is  satisfied  that  the  fora  as  typed  is  correct,  ha  can  activate  it, 
allowing  Lisp  to  road  in  the  fora  and  evaluate  it.  Whan  Lisp  prints  out  the 
result,  it  is  inserted  into  the  buffer  at  the  right  place.  Staple  coaaands  ere 
available  to  fetch  earlier  inputs,  for  possible  editing  and  reactivation. 

In  addition  to  coaaands  froa  the  keyboard,  the  aouse  can  be  used  to  point 
to  parts  of  the  buffer,  and  to  giva  staple  editing  coaaands.  The  use  of  aice  for 
text  editing  was  originated  at  SRI,  and  has  been  refined  and  extended  at 
XEROX- PARC. 

The  character-string  representation  of  each  function  in  a prograa  being 
worked  on  is  stored  in  its  own  editor  buffer.  One  noraally  aodlfies  functions  by 
editing  the  character-string  fora,  then  typing  a single-character  coaaand  to  reed 
it  into  Lisp,  replacing  the  old  function.  Coapilatlon  can  optionally  be 
requested.  The  advantage  of  operating  on  the  character  fora,  rather  than 
directly  on  the  list  structure,  is  that  cooaents  and  the  user's  chosen  formatting 
of  the  code  are  preserved;  in  addition,  the  editor  is  easier  to  use  because  it 
operates  on  what  you  see  on  the  display.  There  are  coaaands  to  store  sets  of 
buffers  into  files,  and  to  get  then  back  again. 

The  editor  has  the  capability  to  edit  and  display  text  in  aultlple  fonts, 
and  aany  other  features  too  nuaerous  to  aention  here. 


CURRENT  STATUS  (August  1977) 

The  original  prototype  CONS  aachine  was  designed  end  built  soaewhat  wore 
than  two  years  ago.  It  had  no  aeaory  and  no  I/O  capability,  and  roaalned  pretty 
auch  on  the  back  burner  while  software  was  developed  with  a slaulator  on  the 
PDP-10  (the  slaulator  executed  the  Lisp  aachine  macro  instruction  set,  a function 
now  performed  by  CONS  microcode.)  Hlcroprograoalng  got  under  way  a little  over  a 
year  ago,  and  in  the  beginning  of  1977  the  aachine  got  aeaory,  a disk,  and  a 
terminal. 

We  now  heve  an  alaost-coaplote  systea  running  on  the  prototype  aechine. 
The  aajor  reaainlng  "holes"  are  the  lack  of  a garbage  collector  and  the  presence 
of  only  the  aost  primitive  error  handling.  Also,  floating-point  and  blg-lnteger 
numbers  and  alcrocoapilation  have  been  put  off  until  the  next  aachine.  The 
systea  Includes  alaost  all  the  functions  of  Nacllsp,  and  quite  a few  new  ones. 
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The  Machine  is  able  to  page  of f of  its  disk,  accept  input  fro*  the  keyboard  and 
the  Mouse,  display  on  the  TV,  and  do  I/O  to  files  on  the  PDP-10.  The  display 
editor  is  conpletely  working,  and  the  conpller  runs  on  the  Machine,  so  the  systen 
is  quite  usable  for  typing  in,  editing,  coaplling,  and  debugging  Lisp  functions. 

As  a demonstration  of  the  system,  and  a test  of  its  capabilities,  two 
large  programs  have  been  brought  over  from  the  PDP-10.  William  Woods's  LUNAR 
English-language  data-base  query  systen  was  converted  from  interLlsp  to  Naclisp, 
thence  to  Lisp  Machine  Lisp.  On  the  Lisp  Machine  it  runs  approxiaately  3 tines 
as  fast  as  in  Maclisp  on  the  LA- 10,  which  in  turn  is  2 to  4 tines  as  fast  as  in 
InterLlsp.  Note  that  the  Lisp  machine  time  is  elapsed  real  time,  while  the 
PDP-10  tines  are  virtual  run  tines  as  given  by  the  operating  systen  and  do  not 
include  the  delays  due  to  tiaosharing. 

Host  of  the  Racsyaa  symbolic  algebraic  systen  has  been  converted  to  the 
Lisp  aachlne;  nearly  all  the  source  files  were  slaply  coaplled  without  any 
Modifications.  Host  of  Hacsyna  works  except  for  sone  things  that  require 
blgnuns.  The  prellninary  speed  is  the  sene  as  on  the  KA-10,  but  a nuaber  of 
things  have  not  been  optiaally  converted.  (This  speed  aeasureaent  is,  again, 
elapsed  tine  on  the  Lisp  aachine  version  versus  reported  ran  tine  on  the  KA-10 
tine  sharing  systen.  Thus,  paging  end  scheduling  overhead  in  the  KA-10  case  are 


not  counted  in  this  aeasureaent.) 

LUNAR  (including  the  dictionary)  and  Hacsyna  can  reside  together  in  the 
Lisp  nachlne  with  plenty  of  roon  left  over;  either  progran  alone  rill  net 
entirely  fit  in  a PDP-10  address  space. 

The  CONS  nachlne  is  currently  being  redesigned,  and  a new  aachine  will  be 
built  soon,  replacing  our  present  prototype.  The  new  nachlne  will  have  larger 
sizes  for  certain  Internal  neaorlos,  will  Incorporate  newer  technology,  will  have 
greatly  laproved  packaging,  and  will  be  faster.  It  will  fit  entirely  in  one 
cabinet  and  will  be  designed  for  ease  of  construction  and  servicing.  In  late 
1977  and  early  1976  we  plan  to  build  seven  additional  Machines  and  Install  then 
at  the  HIT  AI  Lab.  During  the  fall  of  1977  we  plan  to  finish  the  software, 
bringing  it  to  a point  whore  users  can  be  put  on  the  systen.  User  experience 
with  the  Lisp  nachlne  during  1978  should  result  in  improvoaant  and  cleaning  up  of 
the  Software  and  docuaentatlon,  and  should  give  us  a good  idea  of  the  real 
performance  to  be  expected  from  the  aachine.  At  that  tine  wo  will  be  able  to 
start  thinking  about  ways  to  aako  Lisp  aachlaos  available  to  the  outside  world. 
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